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The ’describes’ Link Relation Type 
Abstract 


This specification defines the ’/describes’ link relation type that 
allows resource representations to indicate that they are describing 
another resource. In contexts where applications want to associate 
described resources and description resources, and want to build 
services based on these associations, the ’describes’ link relation 
type provides the opposite direction of the ’describedby’ link 
relation type, which already is a registered link relation type. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This is a contribution to the RFC Series, independently of any other 
RFC stream. The RFC Editor has chosen to publish this document at 
its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6892. 


Copyright Notice 


Copyright (c) 2013 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. 
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1. Introduction 


Resources on the web can be identified by any (registered) URI scheme 
and can be represented by any (registered) media type. In many 
cases, applications establish specific (i.e., typed) relations 
between the resources they are concerned with, which can either be 
under their control or controlled by another authority. A common 
usage pattern for associating resources is to have resources that are 
descriptions of other resources. This specification registers the 
‘describes’ link relation, which allows applications to represent the 
fact that one resource is a description of another resource. 


RFC 5988 [1] "defines a framework for typed links that isn’t specific 
to a particular serialisation or application. It does so by 
redefining the link relation registry established by Atom to have a 
broader domain, and adding to it the relations that are defined by 
HTML". This registration request intends to augment the link 
relation registry with a link relation that is the inverse of the 
already registered ’describedby’ relation, so that links between 
described resources and describing resources can be represented in 
both directions. 


2. Resource Descriptions 


Associating resources with descriptions of these resources is a 
recurring pattern on the web. The IANA "Link Relations" registry 
established by RFC 5988 [1] currently contains a '’describedby’ link 
relation type, which has been registered by POWDER [2]. The 
definition given in the reference document for that registration is 
as follows: "The relationship A /’/describedby’ B asserts that resource 
B provides a description of resource A. There are no constraints on 
the format or representation of either A or B, neither are there any 
further constraints on either resource". 


Wilde Informational [Page 2] 


RFC 6892 describes" Link Type March 2013 


Since many scenarios using resource descriptions need to represent 
the fact that some resource describes another resource (the opposite 
of the ‘’describedby’ relation), this document registers a ’describes’ 
link relation type. Establishing a link A ’describes’ B asserts that 
the resource identified by A is a description of the resource 
identified by B, without constraining in any way the identifiers 
being used for A and B, and the media types for the representations 
being provided when those identifiers are dereferenced. 

Specifically, it is possible that identifiers A and/or B have no 
associated interaction method (they could be URNs, for example), but 
it still is valid to establish the A ‘’describes’ B link. 


Another design freedom is to use "chains" of ’describes’ (or 
'describedby’) links, so that one resource is a description of 
another resource, which in turn is a description of yet another 
resource. The "levels" of descriptions can go as deep as required by 
an application and are not constrained by this specification. 


3. Use Case 


Beginning with the POWDER document [2], which specifies the 
'describedby’ link relation, the use case for the ’describedby’ link 
relation is that a described resource, such as an HTML web page, can 
specify a link where clients can find a description of this resource. 
While the ’describedby’ link relation is defined to be independent of 
specific formats and representations, within the context of POWDER, 
the assumption is that the linked resources most often will provide a 
description based on the Resource Description Framework (RDF), for 
example, to provide metadata about a document’s author and other 
provenance information. 


The ’describes’ link relation allows servers hosting description 
resources to associate those description resources with the resources 
that they are describing. In the RDF-oriented scenario of POWDER, 
this means that a service managing description resources would use 
‘describes’ links to represent the fact that the description 
resources it exposes provide some description of the described 
resource, very likely in some RDF representation. However, since 
link relations are independent of resource formats or 
representations, such an association could also be made in other 
formats such as XML or JavaScript Object Notation (JSON), allowing 
servers to use a single and consistent link relation to associate 
description resources with described resources. 


Generally speaking, the idea of the ’describes’ relation is the same 
as the idea of the ’describedby’ relation; to be independent of 

specific formats and representations of both described resources and 
description resources. The ’describes’ link relation (together with 
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the already registered ’describedby’ link relation) thus serves as a 
general foundation of how described resources and description 
resources can be associated. 


4. IANA Considerations 


The link relation type below has been registered by IANA per Section 
6.2.1 of RFC 5988 [1]: 


Relation Name: describes 


Description: The relationship A ’describes’ B asserts that 
resource A provides a description of resource B. There are no 
constraints on the format or representation of either A or B, 
neither are there any further constraints on either resource. 


Reference: [RFC6892] 


Notes: This link relation type is the inverse of the ’describedby’ 
relation type. While ’describedby’ establishes a relation from 
the described resource back to the resource that describes it, 
‘describes’ established a relation from the describing resource to 
the resource it describes. If B is ’describedby’ A, then A 
‘describes’ B. 


5. Security Considerations 


Resource descriptions should never be treated as authoritative or 
exclusive without relying on additional mechanisms for trust and 
security. Resources can have many (possibly conflicting) 
descriptions, and the ’describes’ link relation type makes no claim 
whatsoever about the authority of the party providing the association 
between the two resources, or about the authority of the party 
providing the description resource. Before making any assumptions 
about the authority of the description resource (both the accuracy of 
the description contained in the description resource, and the 
authority to provide a description of the described resource), 
clients need a context that allows them to understand both the 
authority of the description itself, and the authority to establish 
the ‘describes’ relation. Nobody can stop clients from providing 
misleading unauthorized and/or descriptions, and clients need to have 
both a security and trust framework to allow them to choose between 
trusted and untrusted descriptions. 
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